Host based and other firewalls have been provided to monitor and control outbound network communications from a protected host. Typically, such firewalls are configured to whether the process that initiated an outbound network communication is trusted, either generally or to make the specific communication in question. A common approach is to prompt a user, for example the first time a particular process attempts to communicate via the network, to indicate the extent to which the user wants to permit the requesting process (or, for example, an underlying application or process with which the requesting process is associated) to perform the requested communication and/or other outbound communications. In some cases, the firewall may be configured to allow or block outbound network communication from a particular process without such user interaction, e.g., by “white listing” applications included in a standard approved configuration or “blacklisting” applications and/or other process considered untrustworthy. Depending on the firewall and/or configuration, a process may be indicated by a user to be trusted to perform the particular action(s) it has attempted and/or performed in the past or to perform any outbound network communication.
Typically, to prevent an attacker from taking advantage of a prior decision to trust a particular application or other process by replacing and/or augmenting the trusted code with malicious code, an application or other process is considered to be the same as one previously determined to be trusted only if the name and path match and the associated binary code is identical, as determined for example by a hash or other value computed based at least in part on the binary code. If the binary code is not identical, typically the application or other process is no longer considered to be trusted, even if the name and path are the same as an application or other process determined previously to be trusted. However, the binary code of a trusted application or other process may undergo authorized changes, e.g., a new patch or update, or even a new version with no or only few changes that implicate security concerns (e.g., new network behavior, such as contacting a new server). Under current approaches, a user who installs a patch or update, or a new version of a trusted application, is prompted the first time an application attempts to communicate via the Internet after a patch, update, or new version has been installed, even though the user has previously indicated the application is trusted, which can be a nuisance to users.
Therefore, there is a need for a better way to process network communications by new versions/variants of a previously characterized (e.g., trusted) application or other process.